home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0594.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  5.5 KB  |  149 lines
  1.  
  2. > Date: Tue, 12 Jan 93 0:06:00 CST
  3. > From: Karl Lehenbauer <karl@one.neosoft.com>
  4. >
  5. > Many of the issues that people seem to be grappling with are  
  6. already
  7. > handled by news.
  8.  
  9. Yes ... but on the other hand there are things which are already  
  10. handled by 
  11.  
  12. > For example, we are talking about caching nodes.  News has highly  
  13. evolved
  14. > caching capabilities -- I mean, caching is what it is all about --  
  15. both for 
  16.  
  17. > TCP/IP and UUCP-based links.
  18.  
  19. I agree.  There are some snags with nes, though, for the ultimate  
  20. retrieval tool. One trouble is, news caches documents very simply.  
  21. The distribution scheme is a flood broadcast.  This is  OK for real  
  22. news (shortlived articles), although many sites sag under the load of  
  23. a lot of stuff they never read.  There are strict limit on what  
  24. anyone posts because of the incredible worldwide total system load  
  25. and disk space usage per message.  There is no well-defined algorithm  
  26. for picking up archived news.  The message Id of an article is not  
  27. enough: you need to know at least one of its newsgroups, its date,  
  28. and be able to deduce the archibe node name and the organisation of  
  29. the archive.
  30.  
  31. The conventions of posing FAQ lists and other "periodic postings" are  
  32. in fact an abuse of the prototcol, and would be better served by a  
  33. retrieval protocol rather than a broadcast protocol.
  34.  
  35. I know that the NNTP WG is looking at this sort of area, and maybe we  
  36. should all get together.
  37.  
  38. In a nutshell, if you take all the data everywhere available online  
  39. and put it into news, the news system will die. The use of newsgroup  
  40. names and lists negotiated by system managers to control what  
  41. documents are visible and cached where is too crude, too inflexible  
  42. -- it doesn't scale well.  The caching has to be automatic.
  43.  
  44. All this said, obvioulsy news and retrieval are coming togather,  
  45. which is why we have tried to look for analogies (see previous  
  46. messages to this list) between news articles and grousp to hypertext  
  47. documents and lists at all times.
  48.  
  49. > Someone mentioned the issue of caching and node names, apparently
  50. > node names would have to be rewritten by the cacher or need to be  
  51. made
  52. > machine-independent in some way (?).
  53.  
  54. Don't worry about that.. I think you are referring to a discussion of  
  55. complete vs. partial UILs.  Let's keep that apart...
  56.  
  57. > Article IDs are guaranteed unique
  58. > and are server-independent.  The mechanism for translating article
  59. > IDs to filenames is fast and pretty highly evolved.
  60. > 
  61.  
  62. > Oh, ugh, "Supercedes:" doesn't cut it unless the article  
  63. superceding
  64. > the old one replaces its article ID, which would probably be Bad.
  65.  
  66. Certainly there is a  case for having the "current" version of an  
  67. article and a given "fixed" version of an article each explicitly  
  68. addressable. See  
  69. http://info.cern.ch/hypertext/WWW/DesignIssues/Versioning.html
  70. and linked things for an old discussion of these issues.
  71.  
  72. > Expiration dates can be set with "Expires:",
  73.  
  74. Exactly.  If you read the provisional HTTP2 spec there is
  75. an explicit link to rfc850 under "Expires". (See
  76. /hypertext/WWW/Protocols/HTTP/Object_Headers.html#z5)
  77.  
  78. >  and sites that 
  79.  
  80. > archive certain groups already do special things on  
  81. "Archive-Name:".
  82.  
  83.  
  84. Really?  Tell me more.  Is that in an RFC somewhere?
  85. reference? Example?
  86.  
  87. > Plus news is already ultra-portable.
  88. > 
  89.  
  90. > Is the brief-connection-per-document approach of HTTP still  
  91. necessary
  92. > when the data is widely replicated?
  93.  
  94. As I said above, the mass of data will not be widely replicated.
  95. You don't want a copy of all the data in the phone book, you just  
  96. want access to it, plus a cache (which you may currently keep in you  
  97. diary).  When you're talking about all the phone book sin the world,  
  98. this is still more the case!
  99.  
  100. So theer will in the end be a directory system not unlike X.500 which  
  101. will allow you to find who has the nearest copy of a document you  
  102. want, in a fairly sophisticated way. And you will pick up up from  
  103. that place.  Then you will click again and pick up a reference from  
  104. somewhere else.
  105.  
  106. An important feature of HTTP is that the document is returned with  
  107. the minimum number of round trips. (Sorry for all the people who have  
  108. heard this before).  Conection-oriented protocols like WAIS and NNTP  
  109. have an introductory dialogue which slows down the first fetch by n*  
  110. the distance/speed of light.
  111.  
  112. We probably need horses for courses -- there is nothing wrong with  
  113. keeping a few protcols around optimised for different access  
  114. profiles.
  115.  
  116. (BTW I think there is a need for a point-point low bandwidth protocol  
  117. designed for beating the hell out of a phone line. One that will keep  
  118. the phone line occpied in a very inteligent way with look-ahaed  
  119. fetches of related documents and lists or parts of them so that a  
  120. home user with a big disk can explore with optimised ease when he is  
  121. paying by the minute. Another good student project)
  122.  
  123. > It would be painful to go reap all the references that
  124. > point to expired articles, although if a user traversed to an  
  125. expired
  126. > article, perhaps it could be pulled off of tape or an NNTP  
  127. superserver 
  128.  
  129. > somewhere.
  130. > 
  131.  
  132. > Clearly the authors of WWW think news is important because WWW has 
  133.  
  134. > nice capabilities for accessing NNTP servers.  What, then, is the 
  135.  
  136. > motivation for HTTP as opposed to, say, using news with HTML  
  137. article 
  138.  
  139. > bodies?
  140.  
  141. I hope I've showed that broadcast data can't cover the NIR world. But  
  142. I also hope that we can allow the models to converge and create a  
  143. supermodel which encompases them.  This is the end goal of HTTP2 or  
  144. should we call it NNTP3.
  145.  
  146.  
  147.  
  148.  
  149.